Requirements: Clinical Quality Service for First Responders (FirstAidIQ)
This document captures the Functional (FR) and Non-Functional (NFR) requirements for each feature in the FirstAidIQ Clinical Quality Service. Requirements are linked to the corresponding Aha.io feature references in product II65.How to Read This Document
- FR- prefix denotes a Functional Requirement.
- NFR- prefix denotes a Non-Functional Requirement.
- Each requirement block identifies the Aha.io feature it supports.
- Requirements are numbered sequentially within each feature section.
Phase 1: Foundation & MVP (II65-R-2)
Feature: II65-1 — Clinical Guideline Knowledge Base
Epic: II65-E-1 (Core AI Clinical Decision Support Engine) Aha.io Reference: II65-1Functional Requirements
| ID | Requirement |
|---|---|
| FR-II65-1-01 | The system SHALL provide an ingestion pipeline capable of importing clinical guideline documents in PDF and structured data formats (JSON, XML). |
| FR-II65-1-02 | The system SHALL store version history for every guideline document, recording the version number, effective date, and the identity of the administrator who approved it. |
| FR-II65-1-03 | The system SHALL expose a search and retrieval API that the AI engine can query to obtain relevant guideline content given a clinical query string or intent. |
| FR-II65-1-04 | The system SHALL provide an administrative interface allowing authorised clinical administrators to upload, review, approve, and retire guideline documents. |
| FR-II65-1-05 | The system SHALL enforce an approval workflow for all new and updated guidelines before they become active, requiring sign-off by at least one clinical administrator. |
| FR-II65-1-06 | The system SHALL be pre-loaded with the current St John NZ Comprehensive Clinical Procedures and Guidelines on initial deployment. |
| FR-II65-1-07 | The system SHALL support guidelines from multiple authoritative sources including St John NZ, American Heart Association (AHA), European Resuscitation Council (ERC), and ILCOR. |
| FR-II65-1-08 | The system SHALL allow an administrator to mark a guideline as superseded and automatically route queries to the current active version. |
Non-Functional Requirements
| ID | Requirement |
|---|---|
| NFR-II65-1-01 | The guideline search API SHALL return results within 200ms at the 95th percentile under normal operating load. |
| NFR-II65-1-02 | The knowledge base SHALL support a minimum of 10,000 structured guideline documents without performance degradation. |
| NFR-II65-1-03 | All guideline documents SHALL be stored with AES-256 encryption at rest. |
| NFR-II65-1-04 | The ingestion pipeline SHALL maintain an audit log of every document import, including source, timestamp, and importing user. |
| NFR-II65-1-05 | The system SHALL achieve 99.9% uptime for the guideline retrieval API, measured monthly. |
Feature: II65-2 — AI Voice Guidance Engine
Epic: II65-E-1 (Core AI Clinical Decision Support Engine) Aha.io Reference: II65-2Functional Requirements
| ID | Requirement |
|---|---|
| FR-II65-2-01 | The system SHALL provide wake word detection that activates the voice interface without requiring any touch interaction. |
| FR-II65-2-02 | The system SHALL transcribe spoken clinical queries to text using a speech-to-text engine. |
| FR-II65-2-03 | The system SHALL parse the transcribed query to identify clinical intent (e.g., “CPR protocol”, “medication dose”, “airway management”). |
| FR-II65-2-04 | The system SHALL generate context-aware clinical guidance responses by querying the Clinical Guideline Knowledge Base (II65-1). |
| FR-II65-2-05 | The system SHALL incorporate the active patient record into the context when generating responses (e.g., known allergies, current vitals). |
| FR-II65-2-06 | The system SHALL deliver guidance responses via text-to-speech with adjustable volume and playback speed. |
| FR-II65-2-07 | The system SHALL fall back to displaying guidance on-screen when audio output is unavailable or disabled. |
| FR-II65-2-08 | The system SHALL support interruption of an in-progress audio response when a new wake word is detected. |
Non-Functional Requirements
| ID | Requirement |
|---|---|
| NFR-II65-2-01 | Wake word detection SHALL achieve activation within 200ms of the final phoneme being spoken. |
| NFR-II65-2-02 | Speech-to-text transcription SHALL achieve accuracy greater than 90% in field environments with ambient noise levels up to 85dB. |
| NFR-II65-2-03 | End-to-end latency from query completion to the start of the audio response SHALL be less than 2 seconds at the 95th percentile. |
| NFR-II65-2-04 | The voice engine SHALL function in offline mode for pre-cached guidelines with no network connection. |
| NFR-II65-2-05 | The voice engine SHALL consume no more than 5% additional battery per hour of active standby on a reference device (iPhone 14). |
Feature: II65-3 — Vital Sign Alert & Threshold Engine
Epic: II65-E-1 (Core AI Clinical Decision Support Engine) Aha.io Reference: II65-3Functional Requirements
| ID | Requirement |
|---|---|
| FR-II65-3-01 | The system SHALL ingest streaming vital sign data including heart rate (HR), oxygen saturation (SpO2), blood pressure (BP), temperature, and ECG waveform from connected wearable devices. |
| FR-II65-3-02 | The system SHALL allow clinical administrators to configure alert thresholds per vital sign type, with the ability to set patient-specific overrides. |
| FR-II65-3-03 | The system SHALL classify alerts into three severity levels: Warning, Critical, and Life-threatening, based on the degree of threshold breach. |
| FR-II65-3-04 | The system SHALL deliver alerts via all three modalities simultaneously: audio (voice announcement), haptic (vibration), and visual (on-screen banner). |
| FR-II65-3-05 | The system SHALL perform trend analysis on incoming vital sign streams to detect deterioration trajectories before a threshold is breached. |
| FR-II65-3-06 | The system SHALL log every alert event with timestamp, vital sign value, threshold, severity, and acknowledgement action. |
| FR-II65-3-07 | The system SHALL suppress duplicate alerts for the same ongoing condition until the condition resolves or the responder acknowledges the alert. |
Non-Functional Requirements
| ID | Requirement |
|---|---|
| NFR-II65-3-01 | Alert generation SHALL complete within 1 second from the receipt of the triggering vital sign reading. |
| NFR-II65-3-02 | The alert engine SHALL process data from at least 4 simultaneous wearable device streams per patient without dropped readings. |
| NFR-II65-3-03 | The threshold configuration interface SHALL enforce validation rules preventing physiologically impossible threshold combinations. |
| NFR-II65-3-04 | The system SHALL maintain a false positive rate below 5% for Warning-level alerts during simulated clinical scenario testing. |
| NFR-II65-3-05 | Alert data SHALL be retained for a minimum of 7 years to satisfy clinical audit requirements. |
Feature: II65-4 — Wearable Device SDK & Integration
Epic: II65-E-2 (Real-Time Telemetry & Wearable Integration) Aha.io Reference: II65-4Functional Requirements
| ID | Requirement |
|---|---|
| FR-II65-4-01 | The SDK SHALL support device discovery and pairing using Bluetooth Low Energy (BLE) GATT Health Device Profile. |
| FR-II65-4-02 | The SDK SHALL support simultaneous connection to a minimum of 4 wearable devices per responder device. |
| FR-II65-4-03 | The SDK SHALL provide auto-discovery of certified devices within BLE range without manual configuration by the responder. |
| FR-II65-4-04 | The SDK SHALL monitor and report device status including battery level, signal strength, and data quality indicators. |
| FR-II65-4-05 | The SDK SHALL buffer wearable data locally during network connectivity gaps and transmit buffered data upon reconnection. |
| FR-II65-4-06 | The SDK SHALL include certified profiles for the following initial device set: Polar H10, Apple Watch, Garmin wearables, and generic BLE SpO2 monitors. |
| FR-II65-4-07 | The SDK SHALL provide a documented extension API allowing third-party device manufacturers to add certified device profiles. |
Non-Functional Requirements
| ID | Requirement |
|---|---|
| NFR-II65-4-01 | Device pairing SHALL complete within 5 seconds from the user initiating connection with a certified device. |
| NFR-II65-4-02 | The SDK SHALL not exceed 3% CPU utilisation on the host mobile device when managing 4 simultaneous BLE connections. |
| NFR-II65-4-03 | The SDK SHALL tolerate BLE signal interruptions of up to 30 seconds and automatically re-establish connection without user interaction. |
| NFR-II65-4-04 | The offline data buffer SHALL retain a minimum of 60 minutes of vital sign data per connected device during connectivity loss. |
| NFR-II65-4-05 | The SDK SHALL be distributed as a Swift Package (iOS) with documented integration steps requiring no more than 2 hours for a competent iOS developer. |
Feature: II65-5 — 5G/LTE Telemetry Streaming Pipeline
Epic: II65-E-2 (Real-Time Telemetry & Wearable Integration) Aha.io Reference: II65-5Functional Requirements
| ID | Requirement |
|---|---|
| FR-II65-5-01 | The pipeline SHALL receive real-time vital sign and incident data from mobile field devices via a persistent WebSocket connection. |
| FR-II65-5-02 | The pipeline SHALL implement automatic reconnection with exponential backoff when a WebSocket connection is dropped. |
| FR-II65-5-03 | The pipeline SHALL support automatic network fallback in the order: 5G → LTE → 3G, buffering data locally during the transition. |
| FR-II65-5-04 | The pipeline SHALL store received telemetry data securely and make it available to control centre dashboards (II65-8) and hospital handover systems (II65-9) in real time. |
| FR-II65-5-05 | The pipeline SHALL enforce data sovereignty controls that keep New Zealand patient data within NZ-hosted cloud regions. |
| FR-II65-5-06 | The pipeline SHALL support multi-region deployment to ensure continued operation in the event of a single-region outage. |
| FR-II65-5-07 | All telemetry data in transit SHALL be encrypted using TLS 1.3 minimum. |
Non-Functional Requirements
| ID | Requirement |
|---|---|
| NFR-II65-5-01 | End-to-end telemetry latency from device sensor reading to cloud storage SHALL be less than 500ms on a 5G network. |
| NFR-II65-5-02 | The pipeline SHALL support a minimum of 1,000 concurrent field device connections without throughput degradation. |
| NFR-II65-5-03 | The pipeline SHALL achieve 99.95% uptime, measured monthly, excluding planned maintenance windows. |
| NFR-II65-5-04 | Telemetry data SHALL be retained for a minimum of 7 years with a hot-tier retention of 90 days for rapid query access. |
| NFR-II65-5-05 | The pipeline architecture SHALL be horizontally scalable, allowing capacity to be doubled within 30 minutes using infrastructure automation. |
Feature: II65-6 — FirstAidIQ iOS Application (MVP)
Epic: II65-E-3 (FirstResponder Mobile Application) Aha.io Reference: II65-6Functional Requirements
| ID | Requirement |
|---|---|
| FR-II65-6-01 | The application SHALL support iOS 16 and above on iPhone 12 and newer hardware. |
| FR-II65-6-02 | The application SHALL activate the AI Voice Guidance Engine (II65-2) via a configurable wake phrase. |
| FR-II65-6-03 | The application SHALL allow a responder to create a new patient incident record within 3 taps from the home screen. |
| FR-II65-6-04 | The application SHALL display live wearable vital signs with colour-coded alert banners reflecting severity levels from II65-3. |
| FR-II65-6-05 | The application SHALL operate in offline mode, providing access to cached clinical guidelines without a network connection. |
| FR-II65-6-06 | The application SHALL generate a handover report in PDF format containing the complete incident record, interventions, and current vitals. |
| FR-II65-6-07 | The application SHALL support quick-capture of a minimum of 10 patient demographic and presenting complaint fields on the incident creation screen. |
| FR-II65-6-08 | The application SHALL synchronise all incident and telemetry data to the cloud pipeline (II65-5) when a network connection is available. |
Non-Functional Requirements
| ID | Requirement |
|---|---|
| NFR-II65-6-01 | The application SHALL consume less than 15% battery over a 2-hour operational shift with 4 wearable devices connected and voice guidance active. |
| NFR-II65-6-02 | The application SHALL launch and reach the home screen within 3 seconds on supported hardware. |
| NFR-II65-6-03 | The application SHALL operate within a maximum memory footprint of 200MB under normal use. |
| NFR-II65-6-04 | The application SHALL pass Apple App Store review requirements and be distributed via the App Store or enterprise MDM. |
| NFR-II65-6-05 | The application SHALL support Dynamic Type accessibility settings for all on-screen text elements. |
| NFR-II65-6-06 | Offline cached guidelines SHALL be refreshed automatically whenever the device is connected to a network and an updated guideline is available. |
Feature: II65-7 — Patient Incident Record Management
Epic: II65-E-3 (FirstResponder Mobile Application) Aha.io Reference: II65-7Functional Requirements
| ID | Requirement |
|---|---|
| FR-II65-7-01 | The system SHALL allow a responder to initiate a new patient incident from the home screen in no more than 3 taps. |
| FR-II65-7-02 | The incident form SHALL capture patient demographics: full name, date of birth, gender, known medical conditions, current medications, and known allergies. |
| FR-II65-7-03 | The system SHALL support AVPU (Alert, Voice, Pain, Unresponsive) and GCS (Glasgow Coma Scale) neurological assessment capture. |
| FR-II65-7-04 | The system SHALL allow logging of clinical interventions with timestamps, including CPR, defibrillation, cannulation, and medication administration. |
| FR-II65-7-05 | The system SHALL support voice-dictated notes that are transcribed and attached to the incident record. |
| FR-II65-7-06 | The system SHALL auto-populate vital sign fields from connected wearable devices (II65-4) in real time. |
| FR-II65-7-07 | The system SHALL export completed incident records as HL7 FHIR R4 bundles for integration with hospital EHR systems. |
| FR-II65-7-08 | The system SHALL prevent record deletion; incidents may only be archived with an audit trail. |
Non-Functional Requirements
| ID | Requirement |
|---|---|
| NFR-II65-7-01 | Incident record save operations SHALL complete within 500ms and SHALL not block the UI thread. |
| NFR-II65-7-02 | The HL7 FHIR R4 export SHALL conform to the HL7 FHIR R4 specification and pass validation against the official FHIR validator. |
| NFR-II65-7-03 | All patient data SHALL be encrypted at rest on the device using iOS Data Protection (NSFileProtectionComplete). |
| NFR-II65-7-04 | Records SHALL be retained locally for a minimum of 30 days before automatic archival to cloud storage. |
| NFR-II65-7-05 | The voice dictation transcription accuracy for clinical terminology SHALL exceed 85%, measured against a standardised clinical vocabulary test set. |
Feature: II65-11 — Security & Data Privacy Framework
Epic: II65-E-6 (Regulatory Compliance & Security Infrastructure) Aha.io Reference: II65-11Functional Requirements
| ID | Requirement |
|---|---|
| FR-II65-11-01 | The system SHALL encrypt all patient data at rest using AES-256 and all data in transit using TLS 1.3 as a minimum standard. |
| FR-II65-11-02 | The system SHALL implement role-based access control (RBAC) with the principle of least privilege applied to all service accounts and user roles. |
| FR-II65-11-03 | All user accounts SHALL require multi-factor authentication (MFA) for login. |
| FR-II65-11-04 | The system SHALL maintain a comprehensive, tamper-evident audit log recording every access and modification to patient data, including user identity, timestamp, and action taken. |
| FR-II65-11-05 | The system SHALL enforce patient data residency controls, ensuring NZ patient data is stored and processed exclusively within NZ-hosted infrastructure. |
| FR-II65-11-06 | The system SHALL implement controls to satisfy the NZ Privacy Act 2020, Australian Privacy Act 1988, and GDPR where applicable. |
| FR-II65-11-07 | The system SHALL provide a data export mechanism enabling patient data to be retrieved in a portable format upon subject access request. |
| FR-II65-11-08 | The system SHALL provide a documented data deletion/anonymisation process to support the right to erasure where legally applicable. |
Non-Functional Requirements
| ID | Requirement |
|---|---|
| NFR-II65-11-01 | The system SHALL undergo a penetration test by a qualified third-party security firm at least annually, with no unresolved high-severity findings permitted at time of release. |
| NFR-II65-11-02 | Audit log entries SHALL be available for query within 5 seconds of an auditable event occurring. |
| NFR-II65-11-03 | MFA authentication SHALL complete within 10 seconds under normal network conditions. |
| NFR-II65-11-04 | Security patches classified as Critical SHALL be applied within 24 hours of vendor disclosure; High-severity patches within 7 days. |
| NFR-II65-11-05 | All cryptographic implementations SHALL use industry-standard libraries (e.g., OpenSSL, Apple CryptoKit) and SHALL NOT use custom or deprecated cipher suites. |
Phase 2: Validation & Regulatory (II65-R-3)
Feature: II65-8 — Control Centre Live Operations Dashboard
Epic: II65-E-4 (Control Centre & Dispatch Dashboard) Aha.io Reference: II65-8Functional Requirements
| ID | Requirement |
|---|---|
| FR-II65-8-01 | The dashboard SHALL display the real-time map positions of all active field units alongside each unit’s current incident status. |
| FR-II65-8-02 | The dashboard SHALL provide an expandable panel per field unit showing crew details, active incident summary, and a patient vitals summary. |
| FR-II65-8-03 | The dashboard SHALL generate audio and visual callout notifications for Critical and Life-threatening alerts received from field units. |
| FR-II65-8-04 | The dashboard SHALL support two-way text messaging between control room operators and individual field units. |
| FR-II65-8-05 | The dashboard SHALL implement role-based views distinguishing between dispatcher and clinical supervisor access levels. |
| FR-II65-8-06 | The dashboard SHALL display the status and alert history for a selected patient in a dedicated panel. |
| FR-II65-8-07 | The dashboard SHALL allow operators to acknowledge critical alerts, recording the acknowledgement with timestamp and operator identity. |
Non-Functional Requirements
| ID | Requirement |
|---|---|
| NFR-II65-8-01 | The dashboard SHALL support a minimum of 50 simultaneous active field units per control room operator without UI degradation. |
| NFR-II65-8-02 | The dashboard SHALL be browser-based and fully functional in current-release Chrome, Firefox, and Safari. |
| NFR-II65-8-03 | The map view SHALL refresh field unit positions within 2 seconds of a position update being received from the telemetry pipeline. |
| NFR-II65-8-04 | The dashboard SHALL be accessible and usable at 1920×1080 resolution as a minimum, with responsive layout down to 1280×720. |
| NFR-II65-8-05 | The dashboard SHALL maintain a connection to the telemetry stream via WebSocket and automatically reconnect within 5 seconds of a connection drop. |
Feature: II65-9 — Hospital Pre-Arrival Notification & Handover
Epic: II65-E-4 (Control Centre & Dispatch Dashboard) Aha.io Reference: II65-9Functional Requirements
| ID | Requirement |
|---|---|
| FR-II65-9-01 | The system SHALL automatically trigger a pre-arrival notification to the receiving hospital when the ambulance ETA is 15 minutes or less. |
| FR-II65-9-02 | The notification SHALL initiate a real-time vital signs stream to the hospital ED dashboard for the patient in transit. |
| FR-II65-9-03 | The pre-arrival summary delivered to the hospital SHALL include: presenting complaint, interventions performed, current vital signs, and known patient history. |
| FR-II65-9-04 | The system SHALL deliver and display a hospital acknowledgement confirmation back to the field team upon ED staff accepting the notification. |
| FR-II65-9-05 | The system SHALL integrate with hospital ED information systems via the HL7 FHIR R4 standard. |
| FR-II65-9-06 | The system SHALL support configurable integration profiles for target hospital EHR platforms including Epic, Cerner, and locally hosted systems. |
| FR-II65-9-07 | The system SHALL allow the field team to manually trigger a pre-arrival notification regardless of ETA if clinically indicated. |
Non-Functional Requirements
| ID | Requirement |
|---|---|
| NFR-II65-9-01 | The automated ETA-triggered notification SHALL be sent within 30 seconds of the ETA condition being met. |
| NFR-II65-9-02 | The real-time vitals stream to the hospital dashboard SHALL maintain less than 1 second latency under normal network conditions. |
| NFR-II65-9-03 | The HL7 FHIR R4 integration SHALL be validated against hospital sandbox environments prior to production go-live at each hospital site. |
| NFR-II65-9-04 | The hospital integration SHALL degrade gracefully if the hospital EHR is unavailable, logging the failure and queuing the handover record for manual submission. |
Feature: II65-10 — Clinical Quality Reporting & Protocol Adherence
Epic: II65-E-5 (Clinical Quality & Analytics Platform) Aha.io Reference: II65-10Functional Requirements
| ID | Requirement |
|---|---|
| FR-II65-10-01 | The system SHALL automatically calculate a protocol adherence score for each completed incident, measuring responder actions against the applicable clinical guideline steps. |
| FR-II65-10-02 | The system SHALL flag exceptions where a responder deviated from a guideline step, providing the specific step reference and the recorded action. |
| FR-II65-10-03 | The system SHALL aggregate adherence data and generate trend reports on weekly, monthly, and quarterly intervals. |
| FR-II65-10-04 | The system SHALL provide anonymised peer benchmarking, allowing responders to compare their adherence scores against the organisational average without identifying individuals. |
| FR-II65-10-05 | The system SHALL produce exportable reports in both PDF and CSV formats. |
| FR-II65-10-06 | The system SHALL de-identify all patient data in reports in compliance with GDPR and the NZ Privacy Act 2020. |
| FR-II65-10-07 | The system SHALL allow clinical supervisors to drill down from an aggregate trend report to the individual incident record underlying an exception. |
| FR-II65-10-08 | The system SHALL identify responders with a pattern of guideline deviations and surface them in a training needs dashboard. |
Non-Functional Requirements
| ID | Requirement |
|---|---|
| NFR-II65-10-01 | Report generation for a quarterly summary across 500 responders SHALL complete within 60 seconds. |
| NFR-II65-10-02 | The protocol adherence scoring engine SHALL be auditable, with scoring logic versioned and linked to the guideline version it was derived from. |
| NFR-II65-10-03 | Exported reports SHALL be formatted to a professional standard suitable for regulatory submission without further editing. |
| NFR-II65-10-04 | All analytics processing SHALL use de-identified data; patient identifiers SHALL NOT be present in the analytics data layer. |
| NFR-II65-10-05 | The reporting system SHALL be accessible via the same role-based access control framework defined in II65-11. |
Cross-Feature Non-Functional Requirements
These requirements apply across all features unless explicitly overridden at the feature level.| ID | Requirement |
|---|---|
| NFR-GLOBAL-01 | All system components SHALL be designed for horizontal scalability to support growth from 50 to 5,000 concurrent users without architectural rework. |
| NFR-GLOBAL-02 | All APIs SHALL be versioned (e.g. /api/v1/) and SHALL maintain backward compatibility for a minimum of 12 months after a breaking change is announced. |
| NFR-GLOBAL-03 | All components SHALL emit structured logs (JSON format) to a centralised logging platform. |
| NFR-GLOBAL-04 | The system SHALL provide health check endpoints for all services, used by infrastructure monitoring and load balancers. |
| NFR-GLOBAL-05 | All personally identifiable information (PII) and protected health information (PHI) SHALL be governed by the Security & Data Privacy Framework (II65-11). |
| NFR-GLOBAL-06 | System documentation SHALL be maintained in version control and kept current with each release. |
Feature–Requirement Traceability Matrix
| Aha Feature | Feature Name | Functional Reqs | Non-Functional Reqs |
|---|---|---|---|
| II65-1 | Clinical Guideline Knowledge Base | FR-II65-1-01 to FR-II65-1-08 | NFR-II65-1-01 to NFR-II65-1-05 |
| II65-2 | AI Voice Guidance Engine | FR-II65-2-01 to FR-II65-2-08 | NFR-II65-2-01 to NFR-II65-2-05 |
| II65-3 | Vital Sign Alert & Threshold Engine | FR-II65-3-01 to FR-II65-3-07 | NFR-II65-3-01 to NFR-II65-3-05 |
| II65-4 | Wearable Device SDK & Integration | FR-II65-4-01 to FR-II65-4-07 | NFR-II65-4-01 to NFR-II65-4-05 |
| II65-5 | 5G/LTE Telemetry Streaming Pipeline | FR-II65-5-01 to FR-II65-5-07 | NFR-II65-5-01 to NFR-II65-5-05 |
| II65-6 | FirstAidIQ iOS Application (MVP) | FR-II65-6-01 to FR-II65-6-08 | NFR-II65-6-01 to NFR-II65-6-06 |
| II65-7 | Patient Incident Record Management | FR-II65-7-01 to FR-II65-7-08 | NFR-II65-7-01 to NFR-II65-7-05 |
| II65-8 | Control Centre Live Operations Dashboard | FR-II65-8-01 to FR-II65-8-07 | NFR-II65-8-01 to NFR-II65-8-05 |
| II65-9 | Hospital Pre-Arrival Notification & Handover | FR-II65-9-01 to FR-II65-9-07 | NFR-II65-9-01 to NFR-II65-9-04 |
| II65-10 | Clinical Quality Reporting & Protocol Adherence | FR-II65-10-01 to FR-II65-10-08 | NFR-II65-10-01 to NFR-II65-10-05 |
| II65-11 | Security & Data Privacy Framework | FR-II65-11-01 to FR-II65-11-08 | NFR-II65-11-01 to NFR-II65-11-05 |
| Global | Cross-feature requirements | — | NFR-GLOBAL-01 to NFR-GLOBAL-06 |